home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / ietf / urn / urn-archives / urn-ietf.archive.9701 / 000017_owner-urn-ietf _Wed Jan 29 17:26:38 1997.msg < prev    next >
Internet Message Format  |  1997-02-19  |  5KB
  1. Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id RAA11762 for urn-ietf-out; Wed, 29 Jan 1997 17:26:38 -0500
  2. Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id RAA11756 for <urn-ietf@services.bunyip.com>; Wed, 29 Jan 1997 17:26:35 -0500
  3. Received: from www10.w3.org by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b)
  4.         id AA08401  (mail destined for urn-ietf@services.bunyip.com); Wed, 29 Jan 97 17:26:33 -0500
  5. Received: from peak.w3.org ([18.23.10.162]) by www10.w3.org (8.7.5/8.7.3) with SMTP id RAA27534; Wed, 29 Jan 1997 17:26:40 -0500 (EST)
  6. Message-Id: <3.0.32.19970129172627.007b2140@hq.lcs.mit.edu>
  7. X-Sender: timbl@hq.lcs.mit.edu
  8. X-Mailer: Windows Eudora Pro Version 3.0 (32)
  9. Date: Wed, 29 Jan 1997 17:26:39 -0500
  10. To: Leslie Daigle <leslie@bunyip.com>, urn-ietf@bunyip.com, connolly@w3.org
  11. From: Tim Berners-Lee <timbl@w3.org>
  12. Subject: Re: [URN] what's in a syntax?
  13. Mime-Version: 1.0
  14. Content-Type: text/plain; charset="us-ascii"
  15. Sender: owner-urn-ietf@services.bunyip.com
  16. Precedence: bulk
  17. Reply-To: Tim Berners-Lee <timbl@w3.org>
  18. Errors-To: owner-urn-ietf@bunyip.com
  19.  
  20. I don't follow this consistently, but I am granting myself
  21. the luxury of responding here (with my w3c hat off)
  22. as I think it is important.
  23.  
  24. At 03:25 pm 27-01-97 -0500, Leslie Daigle wrote:
  25. >    . If we align the syntaxes wrt reserved characters, etc, will
  26. >      
  27. >        URN:<see syntax draft of the day>
  28. >
  29. >      necessarily imply that URNs are a "scheme" of URLs?
  30.  
  31. It would be sufficiently confusing that I would certainly oppose
  32. it if it didn't.
  33.  
  34. >      If so, then URNs will have to go through the URL vetting process,
  35. >      and potentially the string "URN" will be objected to.
  36.  
  37. I don't see any reason why anyone should object to a string.
  38. (It would be nice if one were to admit the possibility  of other schemes
  39. which match the URN requirements but are in fact different schemes,
  40. just as you can consider "URL" to be one requirement and "HTTP"
  41. to be a protocol meeting it.  But if the only thing in one's way is an
  42. arbitrary string, then it should not really prevent progress!)
  43.  
  44. >      Also, will this imply that URNs are equivalent to URLs in terms
  45. >      of semantics?  (There are those that think the are, and those that
  46. >      think they aren't). 
  47.  
  48. No, no 1000 times no!   I have tried so many times to say that universal
  49. URI syntax is more universal than the semantics of any "name",
  50. "address", "locator" space.  It is social issues not technical ones
  51. which in the end make the differences between names and addresses
  52. in a global information space.
  53.  
  54. >    . Alternatively, can we align the syntaxes and succeed in having
  55. >
  56. >        URN:<see syntax draft of the day>
  57. >
  58. >      treated as a special case by URL resolvers, (treated as an 
  59. >      opaque URL, as Ryan described it).
  60.  
  61. Hands up those who like special cases.
  62.  
  63. >These questions have little to do with implementation details -- i.e., 
  64. >any of the above can certainly be implemented.  The real questions, to my
  65. >way of thinking, lie in:
  66. >
  67. >    . Does lining up the syntaxes increase the likelihood of getting
  68. >      URNs handled sooner rather than later by existing software (i.e.,
  69. >      are the necessary differences in handling going to mean that
  70. >      existing software can't handle them anyway?)
  71. >
  72. >    . What issues will we have to address in terms of 
  73. >      supporting/distinguishing URN/URL semantics?  (E.g., if URNs
  74. >      are supported as URL "schemes",  can we make the distinction
  75. >      between names and addresses).
  76.  
  77. The semantics of any URI scheme, http: and urn: included, are defined by
  78.  
  79.   - The specification of hte scheme in the rules it allows for changing
  80.    the mapping of URI to content;
  81.  - the social systems set up to ensure that the rules are followed;
  82.  - the extent to which those social systems work;
  83.  - The rules set up, in a hierarchical system, by delegates such as
  84.    URN authorities for URNs or webmasters for HTTP which determine
  85.   how specifically the mapping of URI to content in any given subtree;
  86.  - Similarly, the social systems to enforce those rules and the extent 
  87.  that they work.
  88.  
  89. Historians and librarians of the future will be able to say what worked
  90. in terms of being persistent.
  91.  
  92. >I have not been successful in trying to make this an even-handed message
  93. -- it
  94. >is pretty clear that I am concerned that we are heading back into rough
  95. >waters regarding "why do we need URNs when we have URLs". 
  96.  
  97. If the URN group is going to set up a new name space with good properties,
  98. then that seems to me to have some value.  I also believe in the coexistence
  99. of alternative schemes and (especially when social factors are involved)
  100. the real world and the market testing them and choosing in the end.
  101.  
  102. Tim BL
  103.